backend/app/services/intelligence/github_collector.py (1)

182-212: 🚀 Performance & Scalability | 🔵 Trivial

IaC fetch loop adds up to 30 more sequential round-trips per repo.

The new .tf fetch loop follows the existing manifest/source pattern of awaiting fetch_repo_file one path at a time. Combined with the pre-existing manifest and source loops, a monorepo hitting all three caps could issue dozens of sequential HTTP calls per repo before moving to the next repository, adding to overall GitHub-link pipeline latency.

Consider bounding concurrency (e.g. asyncio.gather with a semaphore) for the fetch loops if link latency becomes a concern, while being mindful of GitHub secondary rate limits.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/services/intelligence/github_collector.py` around lines 182 -
212, The new IaC fetch loop in github_collector.py is still doing one await per
path, which can add many sequential GitHub round-trips alongside the existing
manifest and source loops. Update the fetch flow around fetch_repo_file,
parse_infra, and the selected_infra iteration to use bounded concurrency (for
example with asyncio.gather plus a semaphore) so multiple files can be fetched
in parallel without exceeding rate-limit safeguards. Keep the existing selection
caps and partial-tracking behavior intact while applying the same pattern
consistently across the manifest, source, and infra fetch loops.

backend/tests/test_github_collector_extended.py (1)

420-475: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Missing test for _INFRA_MAX_DEPTH truncation.

The manifest suite has test_depth_cap_drops_deep_paths_and_marks_partial covering _MANIFEST_MAX_DEPTH, but there's no analogous test for _INFRA_MAX_DEPTH (only the count cap and truncated propagation are exercised for infra). Since the collector intentionally sets a different depth cap for .tf (deeper subtrees), a dedicated test would guard that behavior.

✅ Suggested additional test

def test_infra_depth_cap_drops_deep_paths_and_marks_infra_partial(self, monkeypatch):
    """深さ上限超の .tf は落とし infra_partial=True にすること（D10 / D9 c/d）。"""
    monkeypatch.setattr(github_collector, "_INFRA_MAX_DEPTH", 2)
    _decls, _imported, _partial, infra, infra_partial, fetched = (
        self._patched_collect_full(
            ["main.tf", "a/b/c/main.tf"],
            False,
            file_contents={"main.tf": 'provider "aws" {}\n'},
        )
    )
    assert fetched == ["main.tf"]
    assert infra_partial is True

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/tests/test_github_collector_extended.py` around lines 420 - 475, Add
a dedicated infra depth-cap test alongside the existing collector tests: in
test_github_collector_extended.py, extend the GitHub collector coverage for
_INFRA_MAX_DEPTH by monkeypatching github_collector._INFRA_MAX_DEPTH, calling
_patched_collect_full with one shallow .tf and one deeper .tf path, and
asserting the deep path is dropped from fetched while infra_partial becomes
True. Keep the test aligned with the existing depth-cap style used for
_MANIFEST_MAX_DEPTH so the collector’s .tf-specific depth behavior is guarded.